-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do advanced rendering by hooking into render_block for navigation block #19991
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty straight-forward 👍
) | ||
); | ||
} | ||
add_action( 'init', 'register_block_core_navigation' ); | ||
add_filter( 'render_block', 'render_block_navigation', 10, 2 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if the convention is codified anywhere, but typically I would expect to see the add_filter
to be placed immediately following the callback function (render_block_navigation
in this case).
@@ -234,7 +239,7 @@ function build_navigation_html( $attributes, $block, $colors, $font_sizes, $is_l | |||
$html .= '</span>'; | |||
|
|||
// Append submenu icon to top-level item. | |||
if ( $attributes['showSubmenuIcon'] && $is_level_zero && $has_submenu ) { | |||
if ( ! empty( $attributes['showSubmenuIcon'] ) && $is_level_zero && $has_submenu ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What relevance does this change have in the original goal of using the filter instead of a new argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why, but in my local setup while testing, I got a notice of this not being defined. Also I think this check is better than the initial code, if ( $attributes['showSubmenuIcon']
assumes the item exists.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worked well on my tests in the plugin 👍
Thank you for trying this option right away!
I tried to check if this solution works on the core, but we have another problem in core. The code to copy the PHP file is not included so core does not have navigation block PHP. I will submitt a trac ticket very soon to fix this problem.
I think with that problem fixed plus this PR navigation block should start working as expected.
I submitted a patch to include the navigation block PHP in the core. I tested it with the file being proposed in this PR, and things worked as expected. |
This has broken how the render function worked. When it is used through the It was fixed here by using |
It's a good point to raise, but I think it's also worth clarifying that with the revisions in this pull request, it wouldn't strictly be correct to call this function a "render callback" anymore. Perhaps it should have been renamed accordingly. It behaves quite similar, true, but the change reflects the fact that it's intent is to bypass However, that being said, the underlying issue is that this Namely, this bit of logic: It had been changed from: if ( $is_dynamic ) {
$global_post = $post;
$block_content = $block_type->render( $block['attrs'], $block_content );
$post = $global_post;
} ...to: Lines 69 to 76 in 6de983f
Was there some discussion of this, or a corresponding Trac ticket? I didn't see it mentioned in Trac#48104, though it may have been a further evolution of this override from how it was originally forked from the core implementation. |
Description
Instead of implementing any api changes, such as passing the whole
$block
to the render callback, we can hook into therender_block
filter and render the block using the entire$block
contents, with a callback for said filter.This tries to avoid the need to change how the render_callback 's work by adding the changes from Trac ticket #48104
How has this been tested?
Created navigation menus and they all seem to render just as good without the shim, using the filter's callback.